1. Field of the Invention
In general, the present invention relates to process modeling. Specifically, the present invention provides a way to model a process such as a business process that has multiple variations.
2. Related Art
(Business) process modeling is used by organizations to specify how their businesses are being run (e.g., how tasks flow from one to another, who is doing which tasks, what is the business data flow between tasks, etc.). In many instances, processes can be represented and interrelated with one another in a hierarchical tree-like structure whereby a process (root node) can have one or more sub-processes (child nodes), which themselves could each have one or more sub-processes (grandchild nodes), etc.
Process modeling is also used by application solution vendors to describe the business processes they support as a means to better communicate with business users. Performing business process modeling for a large application solution that encompasses multiple domain contexts (e.g. WebSphere® Commerce offered by International Business Machines Corporation) presents a unique challenge. In many instances, the business processes in each of the multiple domain contexts are very similar with the exception of some variations in sub-processes at the “leaves” of the process tree.
FIG. 1 depicts a process tree 10A for a first specific context (e.g., business to consumer (B2C)) and a process tree 10B for a second specific context (e.g., business to business (B2B)). It can be seen that the two trees appear identical except for processes P1.2.2.x (see reference number 12) and P1.2.2.y (see reference number 13) on the lower right corner of trees 10A-B. These are two variations of the same process P1.2.2, one for B2C and one for B2B. Such differences make modeling process trees 10A-B a problem. Specifically, process P1.2 (see reference number 11) cannot be modeled to use both P1.2.2.x and P1.2.2.y. Rather, it can only be modeled to use one of them and two versions of P1.2 will result. One version (P1.2.x) will result for the B2C context to use P1.2.2.x (reference number 12) and another version (P1.2.y) will result for the B2B context to utilize P1.2.2.y (reference number 13).
Once this starts to occur, the phenomenon will propagate up process trees 10A-B and can soon result in process trees 10C-D as shown in FIG. 2. Since P1.x (see reference number 14) and P1.y (see reference number 15) —and similarly for P1.2x (see reference number 16) and P1.2y (see reference number 17)—are essentially the same process, having two variations of it creates management and maintenance problems. This is especially the case for process trees having a multitude of processes and many levels of depth, which means that the problem described here would be amplified and become unmanageable. Another dimension is the number of contexts supported, which could significantly increase the complexity of the problem. One current approach is to have both P1.2.2.x (reference number 12) and P1.2.2.y (reference number 13) defined in a single process P1.2.2 (see reference number 18), as shown in process tree 10E of FIG. 3. Unfortunately, this approach does not work well for tools that perform integrity checking during the modeling. Also, this approach would invalidate the potential of running process simulation or generating to process flow runtime (e.g. BPEL). Still yet, this approach would complicate generation with respect to UML artifacts for implementation.
In view of the foregoing, there exists a need for a solution that solves at least one of the above-mentioned problems.